The concept of authorization in a computer network involves the verification of the identity of a user. This is mainly used as a security feature to ensure that unauthorized access does not occur. There are many different types of authentication available, and the choice of authentication type can be based on many factors, not the least of which is the protocol used in transmitting packets throughout the network. Additionally, each authentication type can have many different styles available. For example, the Open Shortest Path First (OSPF) Internet routing protocol provides for three possible authentication styles: no authentication, simple password authentication, and Message Digest (MD5) authentication. Thus it is sometimes necessary for a network administrator to change the authentication configuration style of the network. Additionally, certain authentication styles, such as MD5, provide for a key to be used cryptographically. Thus, it is sometimes necessary for the network administrator to change the key while remaining within the same style of authentication.
A problem, however, is encountered when altering configuration styles and keys. A network is not a single entity, it is in fact composed of many different devices all communicating to each other. Typically, therefore, a network administrator will need to update many routers throughout the network whenever a common change is required. However, updating many devices can take time, and during that time the system may not run properly and/or unauthorized users may gain access, because some devices may contain the new configuration or key information while others still only have the old configuration or key information. Thus, what is needed is a solution that allows for the seamless updating of configuration or key information.
One solution that has been attempted in the past is to keep a set of timers, one configurable, and one not. This approach was limited to changing key information in the MD5 style and did not apply to style/general configuration changes. In it, a key activation timer, configured by the administrator, was started upon an MD5 key change. The old key was used for transmitting packets before this timer began counting down, and the old key was used for authenticating received packets as well. After the timer activated, the old key was still used for transmitting packets and both the new and the old key were used to authenticate incoming packets.
When the key activation timer lapsed, an old key deactivation timer was started. This old key deactivation timer was not configurable. While the old-key deactivation timer counted down, the new key was used to send packets, and both old and new keys were used to authenticate incoming packets. After the timer ran out, the new key was used to send out packets, and the new key was used to authenticate incoming packets.
This approach had several problems, however. First, the behavior of the authentication state transitions was not consistent. Thus, none-to-simple transitions happened immediately, but MD5 key changes waited for the activation timer. This caused some confusion as to when exactly a new configuration style would be activated. Additionally, the old key deactivation timer would sometimes have a delay that was too long or too short for the network in which it was operating. For example, in a smaller network, changes are iterated through the routers much faster, and the fixed time could be too long, causing unnecessary delay in fully implementing the new key. Additionally, in a very large network, the fixed time could be too slow, causing reliability issues.
What is needed is a solution that does not suffer the drawbacks of the prior art.